Method and apparatus for storing changes to file attributes without having to store an additional copy of the file contents

ABSTRACT

A method of and an apparatus for storing changes to file attributes without having to store an additional copy of the file contents. In a system for maintaining and making changes to content for a website, extranet site or intranet site, memory may be allocated as a backing store. Preferably, the contents of the backing store are saved despite a shutdown or power failure. Information may be stored by the backing store in the form of files, each file including contents and attributes. The content of a file includes the information stored within the file, while the attributes of the file include information relating to the file. When a change is made to the file contents, both the changed version and the version prior to the changes may be stored in the backing store. For each version of the file contents, associated attributes are also stored. However, when a change is made to the attributes of the file without a change to its contents, the newly changed attributes may be stored in the backing store along with the prior version of the attributes. The newly changed attributes and the prior version of the attributes then share the same version of the file contents. By avoiding having to store multiple versions of the file contents, storage space in the backing store is preserved. A pointer may be provided in the backing store which links both the newly changed attributes and the prior attributes to the same copy of the associated file contents.

RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. ProvisionalApplication No. 60/192,244, filed Mar. 22, 2000. U.S. patent applicationSer. No. ______ , filed on the same day as this application, andentitled, “Method Of And Apparatus For Recovery Of In-Progress ChangesMade In A Software Application,” and U.S. patent application Ser. No.______ , filed on the same day as this application, and entitled,“Method And Apparatus For Automatically Deploying Data In A ComputerNetwork,” are hereby incorporated by reference.

FIELD OF THE INVENTION

[0002] The invention relates to management of memory resources. Moreparticularly, the invention relates to management of memory resourcesutilized during development of content for a website, extranet site orintranet site.

BACKGROUND OF THE INVENTION

[0003] Data is typically stored in a computer system in the form of datafiles. A data file may include content and identifying information andmay change over time in response to a variety of events. For example, afile may be named, re-named, moved, copied, updated, supplemented,edited or deleted. Thus, the content of a data file or its identifyinginformation may each be altered several times during the course ofevents. Particularly, for development of a website, extranet site orintranet site, a large quantity of information may need to be stored andmay need to be frequently altered. For example, storage may be requiredfor work-in-progress and published editions of the website, extranetsite or intranet site.

[0004] In computer systems that manage large quantities of data, it isoften desirable to keep track of changes to files. This is typicallyaccomplished by storing a prior version of a file and a new version ofthe file in computer memory each time the file is changed. This storingof file versions can be especially useful in the field of websitedevelopment where it may often be necessary to revert to a prior versionof the website or a portion thereof. A drawback to this technique,however, is that a large amount of physical computer memory can berequired to store the various different versions of the files that makeup the website.

[0005] While the cost of computer memory has generally been decreasing,communication bandwidth has increasingly become a limiting factor incomputer systems. Thus, there has been little incentive to reduce theamount of memory required for data storage except to the extent thatbandwidth-reducing techniques, such as file compression, alsoincidentally reduce memory requirements. However, file compression has adisadvantage of requiring additional processing capability to compressand decompress the files. Further, file compression techniques aregenerally tailored specifically to the type of data contained in thefile and are, thus, not universally applicable.

[0006] Therefore, what is needed is a technique for minimizing theamount of physical memory required for storing various differentversions of changed files. More particularly, what is needed is atechnique for minimizing the amount of physical memory required forstoring various different versions of a file generated duringdevelopment of a website, extranet site or intranet site. It is towardthese ends that the present invention is directed.

SUMMARY OF THE INVENTION

[0007] The invention is a method of and an apparatus for storing changesto file attributes without having to store an additional copy of thefile contents.

[0008] In a computer system that manages a quantity of data, the data isstored in computer memory in form of files. For example, in a system formaintaining and making changes to content for a website, extranet siteor intranet site, physical memory may be allocated for work areas,staging areas and edition areas. Work areas may store in-progresschanges to be made to the content by an individual contributor or groupof contributors. Once the changes are made in the work areas, thechanged content may be submitted to a staging area or areas. In thestaging area, the content changes may be combined. From the stagingarea, the changed content may be forwarded to an edition area or areas.The edition areas may store versions or editions of the content for thewebsite, extranet site or intranet site.

[0009] In addition to the memory that may be allocated for the variouspurposes described above, a physical backing store memory may also beprovided for providing persistent storage for changes and other content.By persistent, what is meant is that the contents of the backing storeare preferably saved despite a shutdown or power failure occurring tothe system of which the backing store is a part.

[0010] Because the website, extranet site or intranet site may allowaccess to a large quantity of data, including, for example, text,graphics and audio information, the backing store memory may need tostore a large quantity of data. This especially true considering thatthe backing store may store work-in-progress and multiple editions orversions of content for the website, extranet site or intranet site. Forexample, the backing store memory may be required store up to threetimes or more the size of the entire content of the website, extranetsite or intranet site.

[0011] Files in the backing store or other memory each include contentsand attributes. The contents of a file include the information storedwithin the file. This may include, for example, the text, graphics andaudio information which is to be accessible via the website, extranetsite or intranet site. The attributes of a file (the attributes may alsobe referred to as “metadata”) include information relating to the file.This may include, for example, the size of the file contents, a timestamp indicating when the file was created or when the file contentswere last changed, an identification of an owner who is the contributorresponsible for the file, an identification of a group to which the fileor its owner belongs and permission information for restricting accessto the file for performing read and write operations on the file.

[0012] The attributes of a file are stored, such as in the backingstore, in association with the contents for the file. When a change ismade to the file contents, both the changed version of the file contentsand the version prior to the changes may be stored in the backing store.For each version of the file contents, associated attributes are alsostored. Because the attributes may include the size of the file and atime stamp indicating when the file was last changed, changes in thefile contents generally result in changes to the attributes.Accordingly, a different set of attributes is stored for each version oft he file contents.

[0013] However, when a change is made to the attributes of the filewithout a change to the contents of the file, the newly changedattributes may be stored, such as in the backing store, along with theprior version of the attributes. The newly changed attributes and theprior version of the attributes then share the same version of the filecontents. In this way, multiple versions of attributes may be associatedwith a single copy of file contents. Thus, storage space in the backingstore is preserved since storage of a separate copy of the file contentsin association with each version of the file attributes is avoided. Apointer may be provided, such as in the backing store, which links boththe newly changed attributes and the prior attributes to the same copyof the associated file contents.

[0014] The present invention is particularly advantageous for reducingthe amount of storage space required in a system for development of awebsite, extranet site or intranet site. This is due, at least in part,to the large quantity of data files generally required to be stored insuch systems and the need to store prior versions of files along withnew versions of the files.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015]FIG. 1 illustrates a computer network system for websitedevelopment in accordance with the present invention;

[0016]FIG. 2 illustrates diagrammatically a work area, a staging areaand an edition area, which may be utilized by the system of FIG. 1;

[0017]FIG. 3 illustrates diagrammatically computer memory, such as thebacking store memory of FIG. 1, for storing files having attributes andcontents in accordance with the present invention;

[0018]FIG. 4 illustrates diagrammatically a file, which is undergoingdevelopment stored in the backing store memory of FIGS. 1 and 3;

[0019]FIG. 5 illustrates diagrammatically files stored in the backingstore memory as a result of making a change to the contents of the fileof FIG. 4;

[0020]FIG. 6 illustrates diagrammatically contents of the backing storememory as a result of making a change to the attributes of the file ofFIG. 4;

[0021]FIG. 7 illustrates diagrammatically contents of the backing storememory as a result of making another change to the attributes of thefile of FIG. 6; and

[0022]FIG. 8 illustrates diagrammatically contents of the backing storememory as a result of making a change to file contents associated withone of the sets of attributes of FIG. 7.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0023]FIG. 1 illustrates a computer network system 100 for websitedevelopment. On development workstations 102, website developers mayadd, remove, edit and examine files for a website. Developmentworkstations 102 may include conventional personal computers, UNIXworkstations, or other workstations that can be configured to developcontent. The development workstations 102 may be connected to adevelopment server 104 via a computer network 106, such as the Internetor a local area network (LAN).

[0024] The development server 104 includes a web server 108 for servingup content to web browsers, and a backing store 110 for storing versionsof website content. The server 108 processes hypertext transfer protocol(HTTP) requests from the development stations 102 for website content(e.g., files). The website files may be physically stored in the backingstore 110 which may be conventional, such as the WINDOWS NT files systemcommercially available from Microsoft Corporation.

[0025] The development server 104 may also include a conventional memory112 (e.g., RAM) and a conventional processor 114, which implements thewebsite development methods of the present invention by executingsoftware 116 stored in the memory 112. An HTTP protocol virtualizationmodule 118 which the processor 114 executes to allow web server 108 tooperate as if it were multiple servers may also be stored in the memory112.

[0026] The development server 104 may be coupled to a website productionweb server 120 via a network 122. Network 122 may be the same network asnetwork 106 or a different network. The web server 120 may also becoupled to the Internet or an intranet 124. When a website is ready tobe posted on the World Wide Web or on an intranet, the developmentserver 104 sends the website content to the production web server 120which then provides Internet or intranet access to the website.

[0027] A website is generally comprised of the contents of an arbitraryfile system. The website development system 100 of the present inventionmay include hierarchical file systems. Each such file system of thepresent invention provides an environment for managing and manipulatingindividual files. When executed, the website development software 116part of the file system enables the management and manipulation offiles. The backing store 110 is where the files and correspondingmetadata (e.g., owner identification, group identification, accesscontrol, file name, modification times, creation times, etc.) may bephysically stored.

[0028] A hierarchical file system of the present invention may bereferred to as an “area.” There may be different types of areasincluding work areas, staging areas and edition areas. A work area istypically a modifiable file system that is used by persons who createand maintain web content for eventual use in a website.

[0029] Memory may be divided into areas utilized for different purposes.For example, FIG. 2 illustrates diagrammatically a work area 200, astaging area 202 and an edition area 204. Though a single work area 200,staging area 202 and edition area 204 are illustrated in FIG. 2, it willbe understood that plural work areas, staging areas and edition areasmay be provided. Files 302-316 (FIG. 3) may be created or modified inthe work area 200. For example, each individual contributor may beassigned a work area, such as the work area 200. Alternately, a group ofcontributors may be assigned a work area. In addition, the work area 200may include a physical memory device which is distinct from memorydevices utilized for the staging area 202, the edition area 204 or thebacking store memory 110 (FIG. 1). For example, the work area 200 mayinclude memory of an individual contributor's personal computer system.

[0030] The staging area 202 is usually an area where content isassembled before it is published. Since the work areas 200 are generallyareas for creating and maintaining content exclusively, the staging area202 (and the edition area 204), may be restricted to only assembling anddisplaying content. By design then, the staging 202 and edition 204areas may be configured as read-only file systems. Any modifications tocontent may then be sent from an editor back to a workstation to performany changes that may be needed. Thus, a task for which content ismodified may reference content in a staging 202 or edition area 204 butwith the modifications actually taking place in a work area 200. Thishelps to maintain the integrity of the content and to simplify theprocess. However, a business may want the system 100 to be moreflexible, allowing other people such as editors to modify the contentdirectly before it is published. The staging and edition areas may thenbe configured as modifiable file systems. Thus, in such an embodiment,content submitted from work areas may be edited in a staging area 202 orin an edition area 204.

[0031] A work area 200 may initially include a virtual copy of an entirewebsite (unless there is no existing website, in which case the workarea may be empty). In other words, a work area 200 may initially havethe same contents as the file system designated as the website. A workarea 200 provides a developer's personal view of a website in which thedeveloper may contribute to the website. For example, in a work area200, developers can freely add, delete and modify website content andsee how their changes fit into the context of the entire website.Changes made by developers in work areas preferably do not affect thewebsite or the work of other contributors in other work areas. This isbecause each work area may be a separate file system. Typically, a workarea is located at a workstation 102 (FIG. 1).

[0032] Developers may integrate their work in a staging area bysubmitting the contents of their work areas 200 into a staging area 202.The staging area 202 is a file system available to multiple developersthat provides a shared view of the website. Thus, a staging area 202 mayhold the collective work of several developers' work areas 200 and mayallow the developers to share and integrate their changes. In a stagingarea 202, the developers can see how their changes fit together. Thestaging area is typically located at the development server 104.

[0033] Copying is said to be “virtual” where areas share directory treessuch that the directory trees do not have to be physically copied. Thecollective work in a staging area 202 changes as different contributorssubmit new content from work areas 200. Work areas 200 are mosteffective when the content and other information in the staging area 202is virtually copied back to one or more private work areas 200. Thishelps to keep the individual work areas 200 up-to-date with respect tothe staging area 202 while contributors are performing website relatedtasks such as creating and maintaining content.

[0034] When the collective work in a staging area 202 is deemed final,its contents can be published to create an edition of the website. Thismay be accomplished by virtually copying contents of a staging area 202onto an edition area 204. Because an edition is typically a read-onlyfile system, it is a frozen snapshot of the content of the entirewebsite. Each edition taken at sequential points in the development of awebsite may be archived and accessible to all developers so thatdevelopers may instantly recall files, entire directories, orreconstruct entire past versions of the website. For example, thecontents of an edition may be virtually copied into a work area to beused as a basis for further development of the website. An edition area204 is typically located in the development server 104. Content (e.g.,an edition) in the development server 104 may be deployed to theproduction server 120.

[0035] In sum, once changes are made to a file in the work area 200, thechanged file may be submitted to the staging area 202. The staging area202 may be utilized for combining changes to files made by variouscontributors in various different work areas 204. Once the changes arecombined in the staging area 202, the changed files may be deployed tothe edition area 204. The edition area 204 may be utilized for storingversions or editions of the content for the website, extranet site orintranet site.

[0036] During this process of making changes, combining and, then,deploying them, the contents of the work area 200, staging area 202 andedition area 204 may be stored in the backing store 110 (FIG. 1). Forexample, once a change made in a work area 200 is submitted to thestaging area 202, the change may be stored in the backing store 110.

[0037]FIG. 3 illustrates diagrammatically a physical computer memorystoring files in accordance with the present invention. In a preferredembodiment, the memory serves as the backing store memory 110 in thesystem 100 (FIG. 1) for website, extranet site or intranet development.Referring to FIG. 3, the memory 110 stores files 302-316, each filehaving attributes and contents. Thus, the file 302 includes attributesF01 stored in association with contents F01-1; the file 304 includesattributes F02 stored in association with contents F02-1; the file 306includes attributes F03 stored in association with contents F03-1; thefile 308 includes attributes F04 stored in association with contentsF04-1; the file 310 includes attributes F05 stored in association withcontents F05-1; the file 312 includes attributes F06 stored inassociation with attributes F06-1; the file 314 includes attributes F07stored in association with contents F07-1; and the file 316 includesattributes F08 stored in association with contents F08-1. It will beunderstood that the memory 110 may form a portion of a conventionalcomputer system or network, including, for example, one or more generalpurpose processors, software for controlling processor operation, andinput/output devices for providing communication among the processorsand external devices.

[0038] The contents of each of the files 302-316 are the informationstored within the file. Because the files 302-316 may be utilized fororganizing data which is to be accessible via a website, extranet siteor intranet site, the contents may include, text, graphic images,sounds, software scripts, and so forth. The attributes of the files302-316 include information relating to each file. This may include, forexample, the size of the file contents, a time stamp indicating when thefile was created or when the file contents were last changed, anidentification of an owner who is the contributor responsible for thefile, an identification of a group to which the file or its ownerbelongs and permission information for restricting access to the filefor performing read and write operations on the file.

[0039]FIG. 4 illustrates the file 302 stored in the backing store memory110. The file 302 of FIG. 4 may be undergoing development. Thus, forexample, a contributor to the website, extranet site or intranet site ofwhich the file 302 is a part, may make an addition, deletion or changeto the contents F01-1 of the file 302. These changes may be made in thework area 200 (FIG. 2) and, then, submitted to the staging area 202(FIG. 2).

[0040]FIG. 5 illustrates diagrammatically files 302, 304 stored in thebacking store memory 110 as a result of making a change to the contentsF01-1 of the file 302 of FIG. 4. The contents F02-1 of the file 304shown in FIG. 5 includes changes, which were made to the contents F01-1of the file 302. Because the contents F01-1 of the file 302 werechanged, the contents F01-1 of the file 302, are stored in the memory110 along with the original version of the contents F02-1 of the file304. For example, the file 304 may be created upon submission of thechanges to the staging area 202 (FIG. 2).

[0041] Because the contents F01-1 of the file 302 were changed, thistends to require that the attributes F01 also be altered. For example,one of the attributes F01 (e.g., a size attribute) may indicate the sizeof the contents F01-1 of the file 302. In which case, a change to thecontents F01-1 would likely result in a change to the size attribute. Asanother example, one of the attributes F01 (e.g., a time stampattribute) may include a time stamp for the last alteration of the filecontents F01-1. In which case, the time at which the contents F01-1 werechanged would be reflected by that attribute. Accordingly, theattributes F02 of the file 304 may differ from the attributes F01 of thefile 302. Thus, as shown in FIG. 5, each set of attributes F01 and F02may be stored in the backing store memory 110 in association with thecorresponding contents F01-1 and F02-1.

[0042] Thus, storage of the files 302, 304 in the memory 110 as a resultof a change to the contents F01-1 of the file 302 has been described.

[0043] Under certain circumstances, however, it may be desired to make achange to the attributes of a file without making any changes to thefile contents. For example, the file may be re-assigned to a new ownerwho is to become the contributor responsible for the file. In whichcase, the attribute (e.g., an owner attribute) that identifies the ownerof the file may be changed without any corresponding change being madeto the file contents.

[0044] If one or more of the attributes F01 of the file 302 is changed,rather than its contents F01-1, a separate copy of the contents F01-1need not be stored along with the changed set of attributes. Rather, asingle copy of the contents F01-1 may be shared by both the original setof attributes F01 and the changed set of the attributes F02. This isshown in FIG. 6, which illustrates diagrammatically contents of thebacking store memory 110 as a result of making a change to theattributes F01 of the file 302 of FIG. 4.

[0045] When a change to the attributes F01 of the file 302 is made, suchas in the work area 200 (FIG. 2), the change may then be submitted tothe staging area 202. As shown in FIG. 6, upon submission of the change,a new set of attributes F02, which includes the changes made to theattributes F01, may be stored in the memory 110 along with the originalset of attributes F01 and the original contents F01-1 of the file 302.In addition, a pointer 600 may be stored in the backing store memory110.

[0046] The pointer 600 includes an indication that the attributes F02are associated with the file contents F01-1. For example, when theattributes F02 are formed, an identification of the pointer 600, such asits memory address, may be included in the attributes F02. Thisassociates the pointer 600 with the attributes F02. The pointer 600 maythen identify the file contents F01-1. For example, the pointer 600 mayinclude a starting address for the file contents F01-1. This associatesthe pointer 600 with the file contents F01-1.

[0047] As a result of utilizing the pointer 600 to associate the filecontents F01-1 with the attributes F02, the file contents F01-1 areshared by both sets of attributes F01 and F02. Accordingly, thisconserves space in the backing store memory 110 because there is no needto store a separate copy of the file contents F01-1 for each of the twosets of attributes F01 and F02.

[0048] If another change is then made to the file attributes F02 of FIG.6, then a third set of attributes F03 may be formed. FIG. 7 illustratesdiagrammatically contents of the backing store memory 110 as a result ofmaking another change to the attributes F01 or F02 of the file 302 ofFIG. 6. For example, if the attributes F02 are changed again, such as tore-assign the file 302 to yet another owner who is to become thecontributor responsible for the file 302, then a new set of attributesF03 may be formed. For example, the set of attributes F03 may be formedupon submission of this change to the staging area 202 (FIG. 2). Anidentification of the pointer 600, such as its memory address, may alsobe included in the attributes F03. This associates the pointer 600 withthe attributes F03 in addition to the pointer 600 being associated withthe attributes F02. Accordingly, the attributes F01, F02 and F03 may allshare the same file contents F01-1.

[0049] Rather than including an identification of the pointer 600 in thenewly formed attributes F03, a new pointer (not shown) may be formed. Inwhich case, the attributes F03 may include an identification of thenewly formed pointer. If the newly formed pointer is to replace thepointer 600, the attributes F02 may also be modified to associate theattributes F02 with the newly formed pointer.

[0050] Thus, storage of the files 302 in the memory 110 as a result of achange to the attributes F01 of the file 302 has been described.

[0051] If, however, a change is then made to the file contents F01-1,but which change is intended to affect the contents associated with onlyone of the sets of attributes F01, F02, F03, of FIGS. 6 or 7, thensharing of the file contents F01-1 may be discontinued. For example,assume that a change or substitution is made to the file contentsassociated with the attributes F03 of FIG. 7, but which is not intendedto change the file contents associated with the attributes F01 and F02.For example, the change may be made in the work area 200 (FIG. 2) and,then, submitted to the staging area 202 (FIG. 2).

[0052] As a result, a new file 308 may be formed, as shown in FIG. 8.The newly formed file 308 includes attributes F04 and contents F04-1.The attributes F04 may be the same as the attributes F03, assuming noattribute changes were made. However, the attributes F04 may be updatedto reflect the changes in the file contents F04-1. For example, a timestamp or file size may need to be altered. The contents F04-1 includethe changes made to the file contents F01-1. The attributes F03 may alsobe retained in the memory 110 in association with the contents F01-1 forthe purpose of tracking these changes to the file 302.

[0053] In general, the invention may include the utilization ofdedicated processors, webservers configured to receive and route browserrequests, application servers, state servers and other types of computerprocessors configured to communicate amongst each other and that may beconnected to one or more networks, including a Local Area Network (LAN),an intranet and the Internet. However, it will be appreciated by thoseskilled in the art, such implementation of such devices and systems arebut few illustrations of the utility of the invention, and that theinvention may have greater applicability and utility in many otherapplications where efficient routing and processing of data within oneor more networks is involved. Equivalent structures embodying theinvention could be configured for such applications without divertingfrom the spirit and scope of the invention. Although this embodiment isdescribed and illustrated in the context of devices and systems forexchanging data among users of a computer system or network, theinvention extends to other applications where similar features areuseful. The invention may include personal computers, applicationservers, state servers or Internet webservers that are designed andimplemented on a computer and may be connected to a network forcommunication with other computers to practice the invention. A systemconfigured to operate according to the invention may include a pluralityof personal computers connected to the Internet via individual modems orother communication means such as wireless communications.

[0054] The invention may also involve a number of functions to beperformed by a computer processor, such as a microprocessor. Themicroprocessor may be a specialized or dedicated microprocessor that isconfigured to perform particular tasks by executing machine-readablesoftware code that defines the particular tasks. The microprocessor mayalso be configured to operate and communicate with other devices such asdirect memory access modules, memory storage devices, Internet relatedhardware, and other devices that relate to the transmission of data inaccordance with the invention. The software code may be configured usingsoftware formats such as Java, C++, XML (Extensible Mark-up Language)and other languages that may be used to define functions that relate tooperations of devices required to carry out the functional operationsrelated to the invention. The code may be written in different forms andstyles, many of which are known to those skilled in the art. Differentcode formats, code configurations, styles and forms of software programsand other means of configuring code to define the operations of amicroprocessor in accordance with the invention will not depart from thespirit and scope of the invention, which is defined by the appendedclaims.

[0055] Within the different types of computers, such as computerservers, that utilize the invention, there exist different types ofmemory devices for storing and retrieving information while performingfunctions according to the invention. Cache memory devices are oftenincluded in such computers for use by the central processing unit as aconvenient storage location for information that is frequently storedand retrieved. Similarly, a persistent memory is also frequently usedwith such computers for maintaining information that is frequentlyretrieved by a central processing unit, but that is not often alteredwithin the persistent memory, unlike the cache memory. Main memory isalso usually included for storing and retrieving larger amounts ofinformation such as data and software applications configured to performfunctions according to the invention when executed by the centralprocessing unit. These memory devices may be configured as random accessmemory (RAM), static random access memory (SRAM), dynamic random accessmemory (DRAM), flash memory, and other memory storage devices that maybe accessed by a central processing unit to store and retrieveinformation. The invention is not limited to any particular type ofmemory device, nor any commonly used protocol for storing and retrievinginformation to and from these memory devices respectively.

[0056] While the foregoing has been with reference to particularembodiments of the invention, it will be appreciated by those skilled inthe art that changes in these embodiments may be made without departingfrom the principles and spirit of the invention, the scope of which isdefined by the appended claims.

What is claimed is:
 1. A method of storing changes to an attribute of afile comprising steps of: altering an attribute of a file, prior to saidaltering, the attribute being included in a prior set of attributes ofthe file stored in a memory device; storing in the memory device a newset of attributes, said new set of attributes including the alteredattribute; storing in the memory device a single version of filecontents; and sharing the file contents by the prior set of attributesand the new set of attributes.
 2. The method according to claim 1 ,wherein said altering is performed in connection with the development ofa website, extranet site or intranet site and wherein the file contentsincludes information which is to be accessible via the website, extranetsite or intranet site.
 3. The method according to claim 2 , wherein saidaltering is performed in a work area and further comprising submittingthe altered attribute for storage in the memory device, the memorydevice being part of a development server.
 4. The method according toclaim 1 , further comprising forming a pointer in response to saidaltering the attribute wherein the pointer associates the new set ofattributes with the file contents.
 5. The method according to claim 1 ,further comprising: altering the file contents; and discontinuing saidsharing of the file contents in response to said altering of the filecontents.
 6. The method according to claim 5 , further comprising:storing a new file contents, the new file contents including the filecontents as altered by said altering the file contents.
 7. The methodaccording to claim 5 , further comprising retaining in the memory devicethe file contents, prior to being altered by said altering the filecontents, in association with one of the prior set of attributes or thenew set of attributes.
 8. The method according to claim 5 , wherein saidstoring stores the new file contents in association with the new set ofattributes when the file contents are accessed via the new set ofattributes for performing said altering and further comprising updatingthe new set of attributes so as to reflect the changed file contents. 9.The method according to claim 5 , wherein said storing stores the newfile contents in association with the prior set of attributes when thefile contents are accessed via the prior set of attributes forperforming said altering and further comprising updating the prior setof attributes so as to reflect the changed file contents.
 10. The methodaccording to claim 1 , further comprising: altering an attribute of thenew set of attributes thereby forming a third set of attributes; sharingsaid file contents by the prior set of attributes, the new set ofattributes and the third set of attributes.
 11. The method according toclaim 10 , further comprising forming a pointer in response to saidaltering an attribute wherein the pointer associates the new set ofattributes and the third set of attributes with the file contents. 12.The method according to claim 11 , wherein the new set of attributes andthe third set of attributes each includes an identification of thepointer.
 13. The method according to claim 10 , further comprising:forming a first pointer in response to said altering an attribute of thefile, wherein the first pointer associates the new set of attributeswith the file contents; and forming a second pointer in response saidaltering the attribute of the new set of attributes wherein the secondpointer associates the third set of attributes with the file contents.14. The method according to claim 13 , wherein the new set of attributesincludes an identification of the first pointer and wherein the thirdset of attributes includes an identification of the second pointer. 15.An apparatus for storing changes to an attribute of a file, theapparatus having physical memory comprising: a work area including afile undergoing development, the file having a prior set of attributesand file contents; and a staging area for receiving an alteration madein the work area to an attribute of the prior set of attributes whereinin response to receiving the changed attribute, a new set of attributesis stored in the memory, the new set of attributes including the alteredattribute and the file contents being shared by the prior set ofattributes and the new set of attributes.
 16. The apparatus according toclaim 15 , further comprising an edition area for storing contents of awebsite, extranet site or intranet site and wherein the file contentsincludes information which is to be accessible via the website, extranetsite or intranet site.
 17. The apparatus according to claim 15 , whereinsaid memory further comprises a persistent backing store memory forstoring the prior set of attributes, the new set of attributes and theshared file contents.
 18. The apparatus according to claim 15 , furthercomprising a pointer stored in the memory for associating the new set ofattributes with the file contents.
 19. The apparatus according to claim15 , wherein when an alteration is made to the file contents in the workarea, the file contents are no longer shared by the prior set ofattributes and the new set of attributes.
 20. The apparatus according toclaim 19 , wherein a new file contents, as altered by said alteration tothe file contents, is stored in the memory.
 21. The apparatus accordingto claim 20 , wherein the memory device stores the file contents, priorto being altered by said alteration to the file contents, in associationwith one of the prior set of attributes or the new set of attributes,said prior set of attributes or new set of attributes updated so as toreflect the changed file contents.